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ABSTRACT 


With the rapidly growing demand for portable devices such as laptops, handheld 
computers and Personal Digital Assistants (PDAs) with wireless networking capabilities, 
the need for reliable wireless data network communication has also increased. Just like 
in mobile voice communication, users demand uninterrupted, secure wireless data 
communication as they move from place to place. Mobile IP satisfies some of these 
demands - it enables mobile devices with fixed IP addresses to be permanently reachable 
even as their point of attachment to the network changes. This allows for routing of data 
packets to and from the mobile device irrespective of its location on the network. While 
uninterrupted data flow can be achieved with Mobile IP, it introduces additional security 
vulnerabilities, including data privacy, data integrity and authentication. The goal of this 
thesis is to investigate such vulnerabilities and explore implementations to overcome 
them. 
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I. INTRODUCTION 


The rapid growth of new and competing radio technology has allowed designers 
to create devices with a very small form factor but significantly enhanced functionality. 
This small form factor and added functionality has increased mobility, which, in turn, has 
increased the popularity of devices such as PDAs, handheld computers and laptops. With 
wireless functionality built into these devices, people are now able to access information 
easily. The popularity of wireless technology has rapidly increased as new “hotspots” 
have popped up across the nation. These “hotspots” include places such as airports, 
coffee shops, school campuses and public libraries. As more of these places are 
established, the concern for security grows larger because information is transmitted over 
the air on radio waves, anyone with radio equipment can intercept sensitive information 
and masquerade their location [BOR1], 

Security risks of wireless include insertion attacks, interception and monitoring of 
wireless traffic, misconfiguration, jamming, and client-to-client attacks. Other attacks 
include broad network exposure, invisible intruders, guest access, and rapid technology 
evolution [SIG]. These risks are being handled using such technologies such as Wired 
Equivalent Privacy (WEP), dynamic WEP, firewalls and encrypted tunnels (VPN, IPSec, 
etc), and wireless LAN managers such as REEFEDGE [SIG]. 

Wireless mobility is very useful for people who want to stay connected to the 
Internet or a network all the time. Wireless mobility is nothing new, but new technology 
has it made more convenient and lowered the cost, which, in turn has made wireless 
mobility more desirable. In our fast paced world, mobility allows a convenient way for 
people who are always on the move to stay connected and efficiently get more work 
done. With the addition of Mobile IP, the hassles of staying connected will be lessened. 
It will provide the “mobility” of the cell phone to Mobile IP networks. 

This thesis uses IP networking and network protocols. We assume the reader is 
knowledgeable of specifics such as the format of IP data packets (i.e. the number of bits 
in a packet, the size of the header, etc.), networking basics (OSI stack), and basic network 
security issues (eavesdropping, replay attacks, etc.) 
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A. PURPOSE 

Our overall goal is to research and implement Mobile IP securely using IPSec. 
One of the goals of Mobile IP is to traverse access points with out losing connectivity. 
Ultimately Mobile IP will allow one to download a 10 MB file or perform a business 
transaction while driving down the highway. Security concerns arise when business and 
personal information is transmitted in the clear over the air. 

IPSec, the Internet Security protocol, is a suite of protocols that provides integrity, 
confidentiality, protection against replay attacks, etc. Our research focuses on security 
within Mobile IP. This thesis will explain Mobile IP, its need in the wireless arena, and 
how security can be implemented. We examine Mobile IP in IPv4 and the security issues 
involved with Mobile IP. We investigate the benefits of using Mobile IP since as a 
society we are becoming more mobile the way we do business and pleasure. 
Telecommuting has increases significantly compared to a decade ago and the use of 
cellular telephones has grown exponentially. 

Our research focuses on security enhancements for Mobile IP. More specifically, 
we look at IPSec and how to implement it within a Mobile IP implementation. After 
examining IPSec within Mobile IP, we discuss the problems and issues that are involved 
with it. 

We also examine how to provide a secure channel, and the different integrity 
issues involved. With each handoff, there is going to be a configuration change between 
the different agents and the mobile node. 


B. THESIS OUTLINE 

This thesis is divided into 6 chapters. Chapter I introduces the different concepts 
and technologies involved with Mobile IP. Chapter II covers the discussion on Mobile IP 
and goes into the details of Mobile IP in general. Chapter III goes into more detail and 
we discuss the specific implementation of Mobile IP that we used for this thesis. Chapter 
IV covers security associated with wireless and a solution to the weak security provided 
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by Mobile IP. Chapter IV discusses the problems we had with implementing Mobile IP. 
We feel this section will be very helpful to the interested reader implementing Mobile IP. 


C. BACKGROUND 

Among the rapidly growing current technologies mobile telephony and wireless 
data networking are near, if not at, the top. Just like with mobile telephones, people want 
their data devices to remain connected as they roam from place to place. Currently 
limited roaming is available with IP based networks. However, there is a lot of current 
research and work going into combining cellular technology with Mobile IP. These two 
technologies are very similar in functionality and therefore we feel it is important to 
discuss them in this thesis. 


1. Mobile Telephony 

Mobile IP works similarly to cellular technology. In this section we will discuss 
briefly how cellular technology works and then compare it to Mobile IP. Figure 1 is a 
very simplified diagram of the components in cellular telephone systems. [ALE]. 



Figure 1. Base Stations and Cell Sites 


For TDMA and CDMA systems, the phone maintains a cell site location. When a 
user dials a number from his/her cell phone and pushes the send button, the phone first 
requests authorization to make a call. Next, the base station checks the phone’s 
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mechanical serial number (MSN) and electronic serial number (ESN) [ALE]. The ESN is 
a unique identification number built into a cell phone for security and billing purposes. 
The MSN is the actual hardware number. It is used most in cases where the phone gets 
lost or stolen. 

After authorizing the call, the base station sends a channel assignment message to 
the phone where the phone is issued a channel to talk. If the phone is analog, the voice 
signal is sent as a modulated radio wavelength [ALE], Else if the phone is digital, the 
voice is sent as a binary digital language in ones and zeros. Next, the base station 
connects a landline call to the mobile switching center (MSC) through Public Switch 
Telephone Network (PSTN), the local phone network; to the number dialed, and then 
conversation can begin. 

The PSTN enables the members of the general public to communicate with each 
other. The MSC is the interface between the radio (i.e., radio waves) system and the 
public switched network. The MSC performs all signaling functions that are necessary to 
establish calls to and from mobile stations [YHL]. The PSTN is the nationwide 
telephone switching system operated by various telephone companies [YGL]. 

In a call from one cell phone to another, the mobile switching center tries to find 
the caller. However, previous to this the cell phone transmits a registration request to the 
MSC. If the system identification code programmed on the caller’s phone matches with 
that of the MSC then the caller’s phone knows it is at home. The MSC knows which cell 
the phone is in when it wants ring the phone [STF]. Within GSM, the BSC is responsible 
for the radio resource (RR), which is a protocol that controls the resources over an air 
interface, frequency administration and handover between BTTs controlled by the BSC. 
One of the goals of a cellular system is for the user to remain connected even as he/she 
moves through the system from one BTT to the next and from one MSC to the next. 

In cellular technology Code Division Multiple Access (CDMA) does soft 
handoff. CDMA refers to the IS-95 standard, which is a transmission protocol that 
employs CDMA, which is just a means to transmit bits of information. In CDMA when a 
phone switches cell sites a soft handoff occurs. In a soft handoff situation the cell sites 
share the same frequency. When a cell is at the edge of its cell site the phone only needs 
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to change the pseudo-random sequence it uses to decode the desired data from the all the 
bits sent for everyone else. While a call is in progress the network chooses two or more 
alternate sites that it feels are handoff candidates. It broadcasts a copy of the call on each 
of these sites simultaneously. The caller’s phone then chooses between the different 
sources for the call, and moves between them whenever it feels like it. It can even 
combine the data received from two or more different sites to ease the transition from one 
to the other [ARX], In most other technologies hard handoff occurs when the network 
informs a user’s phone of the new channel to switch to which it must switch. The phone 
then stops receiving and transmitting on the old channel, and continue transmitting and 
receiving on the new channel. [ARX] 

Lastly, when the call is received the digital data, or radio waves, are converted 
back into voice [ALE], In this thesis we will show the similarities and differences 
between Mobile IP and cellular technology and how they relate to one another. Table 1 
shows a comparison of Mobile IP and mobile telephony. 
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II. MOBILE IP 


A. ARCHITECTURE OF MOBILE IP 

The Request For Comment (RFC) 2002 by Charles Per ki ns [PER2] introduces 
and defines the concept of Mobile IP. A Mobile IP network involves several different 
components. The basic components of Mobile IP consist of a mobile node (MN), home 
network (HN), home agent (HA), foreign network (FN), foreign agent (FA), and 
correspondent node (CN). Figure 2 shows the various Mobile IP components, including 
examples of each the hosts’ network numbers, or network prefixes, which is the network 
number field and leading portion of a 32-bit IP address, identifying the network number 
(Figure 3) [3CO], 



Mobile Node 
1.0.0.5 


Figure 2. Mobile IP Components 
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bit# 01 


7 8 


31 


Network. 

Number 


Host Number- 


Figure 3. IP Address Format [3CO] 


For a more detailed description on IP addressing please refer to [3CO]. Figure 2 also 
shows examples of possible interfaces with IP addresses belonging to an agent (i.e. ethO 
and ethl) and examples of Access Points (AP) and their IP addresses that the MN creates 
the wireless connection to. The following is a detailed description of each component: 

• Mobile Node (MN): This can be any mobile device such as a laptop with 
wireless connectivity, wireless PDA, wireless handheld computers, etc. with 
wireless connectivity 

• Home Network (HN): A MN will have a fixed (constant) IP address (name) 
that is registered on this network. The network prefix of this network is the 
network prefix of the MN. 

• Foreign Network (FN): Any network other than the HN, which has a different 
network prefix from the MN 

• Home Agent (HA): Essentially a router that has at least one interface whose 
network prefix is the same as the MN’s home network. This is the original 
point of attachment that the MN is registered to. Point of attachment refers to 
the current agent (HA or FA) that the MN is connected to. 

• Foreign Agent (FA): Essentially a router that is a potential point of 
attachment, which has at least one interface whose network prefix is different 
from the MN’s network prefix 

• Access Points (AP); A station that transmits and receives data wirelessly. The 
physical interface, which MNs wirelessly connect to. 
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A node’s IP address is the unique identifier for its point of attachment to the 
Internet. Before Mobile IP there were two ways in which a MN could change its point of 
attachment without losing its ability to communicate. One involves changing the node’s 
IP address whenever its point of attachment changed and the other involves propagating 
host-specific routes throughout the Internet routing arrangement [PER2], If all gateways 
had to update their routing tables every time a mobile host changed its point of 
attachment, the size of the routing tables would become enormous. 

Figure 4 is an example of the different states that a Mobile IP Network may 
encounter. This diagram is to be used as a reference for the tables that follow. When the 
MN moves from one network to the other (i.e. from HN to FN1), the host-specific route 
table for each host (FA, Server, and HA), must all get updated by first deleting a route 
and then adding the new route to the table. The following tables show how a host- 
specific route table will change as the MN moves into the different networks. 


9 




MN 

IP: 1.2.3.15 


Figure 4. MN in Different States within a Mobile IP Network 
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Destination Host 

Route To 

1.2.3.0 

1.2.3.10 


Table 1. Host-Specific Route Table, MN in State 1 (see Figure 4) 

When the MN is in the HN, the host-specific route tables of each of the 
components (FA or Server) contain the entry seen in Table 2. The Destination Host 
column contains the network prefix of the network that data will be sent to. The Route 
To column contains the gateway through which the data packets will be sent. Once the 
gateway receives packets, it forwards them to the ultimate destination. However, when 
the MN moves to another network, the tables will change. The following tables show 
this change. 


Table 2. 


Destination Host 

Route To 

2.3.4.0 

2.3.4.10 


Host-Specific Route Table, MN in State 2 (see Figure 4) 


Table 3 shows the updated table of the components. When the MN moves into 
State 2, the previous entries of the host-specific route tables are deleted and replaced with 
the updated information. 


Destination Host 

Route To 

3.2.1.0 

3.2.1.10 


Table 3. Host-Specific Route Table, MN in State 3 (see Figure 4) 

In Table 4, the MN has moved into State 3, where the network prefix is 3.2.1.0. 
Once again, the previous entries in the table are deleted and replaced with the new 
information. 


There are several problems associated with these mechanisms. The first 
mechanism, changing the IP address of a MN whenever the point of attachment changes, 
makes it impossible for a node to maintain its current session level connections. This 
approach makes the end user reestablish a new connection, losing the information that 
was originally being sought after. 

The second mechanism has scaling problems [PER2]. As described in [SKE], by 
next year users will prefer to access the Internet on the go with a wireless Internet device 
rather than sit down in front of a PC. Shipments of wireless Internet devices should reach 
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double and triple digit growth through 2004. As more and more wireless devices are 
activated on the web, the second mechanism will pose a big problem for handling all the 
mobile devices. 

Mobile IP addresses these problems by enabling the MN to keep its IP address 
throughout its connected session. As a MN moves from one subnet to another, the IP 
address is kept the same. This is done through a link-layer handoff during the move. 
When a MN moves from its home network to a foreign network, it must go through 
several phases to seamlessly handoff. The different phases are characterized by agent 
discovery, a registration process and tunneling considerations. 

1. Agent Discovery 

Agent discovery is the process by which a mobile node determines which network 
it is currently connected to, whether at home or a foreign network. It also allows a 
mobile node to detect when it has moved from one network to another. 

The primary method used for agent discovery is the ICMP Router Discovery 
method [PER2]. Both home agents and foreign agents use this method to periodically 
broadcast advertisement messages (Figure 5). These messages contain information about 
the addresses of mobility agents and supported services [MAL], They also contain a 
lifetime value, which determines how long they are valid [PER2]. These messages are 
used by the MN to determine whether or not it has moved. Optionally, a MN may send 
an agent solicitation broadcast message to quickly find a foreign agent to form an 
association with. 
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Mobile Node 


Figure 5. Agent Discovery (Agent Advertisements) 

Each foreign agent sends three unsolicited advertisements during the lifetime of 
its advertisement messages (Figure 6). If a mobile node misses three consecutive 
advertisements, it can deduce that the last advertisement it previously received has 
probably expired [MAL], Upon expiration, the mobile node assumes the foreign agent is 
unreachable and tries to find a different foreign agent. 
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*- 1 
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^- 


Last advertisement expired, 
Find new FA 


Agent advertisement 


Figure 6. Expiration of Lifetime of Advertisements 


A mobile node can also detect that it has moved to a new network using the 
network prefix of the advertisements. In Figure 7, the IP address of the HA is 1.2.3.10 
with a network prefix of 1.2.3.0/24. The IP address of the MN is 1.2.3.5, which has the 
same network prefix as the HA. Once the MN moves to a FN, the agent advertisement 
that it receives has an IP address of 3.2.1.10, with a network prefix of 3.2.1.0/24. The 
network prefix of the FA is different from the MN’s network prefix. A mobile node 
initially starts out accepting agent advertisements from its HA, which contain the home 
network’s address prefix. After it moves, it will start receiving advertisements from other 
agents. Once a mobile node receives an agent advertisement from an agent with a new 
network address, it assumes that it is in a new subnet [MAL], 

Once the MN detects that it is in a new network, it must obtain a collocated care- 
of address (CCOA) or a care-of address (COA). 
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1.2.3.5 



Figure 7. MN Detects New Network from Network Prefix 

A CCOA is a temporary IP address that the MN obtains from the FN, through 
DHCP. This protocol has been discussed in detail in section C of this chapter. A COA is 
a temporary IP address contained in the FA agent advertisement that the MN uses to 
receive data packets; it usually represents an interface on the FA. Both care-of addresses 
are the exit point of the tunnel (this will be explained later in Routing/Tunneling). After 
the MN obtains the correct care-of address, the MN must then register with its HA. 

2. Registration 

Once a mobile node determines that it has entered a new network and obtains a 
care-of address, it registers its care-of address with its HA. This allows the MN to inform 
it’s HA of its current point of attachment. There are two ways that the mobile node can 
register with its HA, depending on its method of attachment. 

In the first method, the mobile node can register directly with its HA. Within this 
first method, there are two scenarios that can take place. The first scenario occurs when 


15 









the MN returns from a FN to its HN. In the sequence diagram below, the MN’s original 
IP address is 1.2.3.5 (Figure 8). When it returns home, it receives agent advertisements 
from the HA that contain the IP address of 1.2.3.10. Once the MN detects that it’s home, 
it then sends a registration request directly to the HA. 
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Figure 8. Registration (MN Returning to HN) 


In the other scenario, the MN obtains a CCOA from the FN. It uses this IP address as the 
endpoint of the tunnel between it and the HA. In the sequence diagram below, after 
receiving agent advertisements from the FA, the MN detects, from the network prefix of 
the advertisement (i.e. IP of FA is 3.2.1.10) that it is in a foreign network (Figure 9). 
Once the detection is made, the MN obtains a CCOA (i.e. 3.2.1.25) through DHCP from 
the FA. It then registers its new CCOA directly with its HA, who replies to the CCOA. 
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Figure 9. Registration (MN in FN with CCOA) 


In the second method of registration, after the MN detects it is in a FN, it registers 
through a FA, which forwards the registration to the HA (Figure 10) [PERI], Once the 
HA receives the registration request, it does a check on the authenticity of the request 
(this will be explained later in the section Authentication in Registration ). After the 
request is authenticated, the HA sends a registration reply back to the MN at the COA. 
Whichever method is used to register, the home agent uses the same method to send a 
reply message. This reply message lets the mobile node know whether or not the 
registration was successful. 
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Figure 10. Registration 


Registration changes or generates a mobility binding, which is the association of a 
home address with a care-of address, along with the remaining lifetime of that association 
at the HA [PERI]. There are important fields that are included in the registration request 
from the mobile node to create the mobility binding. This request contains a new care-of 
address for the mobile node, specific flags for the connection type and authentication data 
[MAL]. Whether the registration is done directly to the HA or through the foreign agent, 
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this mobility binding is maintained. Either way, the agent’s data structures are updated 
and the home address of the mobile node is associated to its current care-of address and 
lifetime of the binding. If registration is performed through the foreign agent, the data 
packets are forwarded to the current point of attachment of the mobile node. Once the 
authentication to protect the data from unauthorized changes by the HA, the foreign agent 
can then update its bindings [MAL], 

As previously mentioned, each mobility binding contains a lifetime. Once it 
expires, the binding gets removed automatically [MAL], It is the responsibility of the 
mobile node to keep the mobility binding alive. Before the lifetime expires, the mobile 
node must reregister. If a mobile node does not receive a registration reply before the 
lifetime expires, it periodically sends a registration message until it receives a reply. 

a. Authentication in Registration 

The registration request packet contains registration extensions, which 
define the authentication measure (Figure 11) [PERI], Each extension has a Security 
Parameter Index (SPI), which indicates the mobility security association. The mobility 
security association contains the secret (i.e. private/public key pair), an authentication 
algorithm (default is keyed MD5), and a style of replay protection (i.e. nonces or 
timestamps), which are all used in calculating the authenticator [PERI]. Keyed MD5 
uses prefix+suffix mode, meaning it creates a secret that is placed before and after the 
data to be authenticated [PERI], The authenticator is the parameter used to authenticate 
the MN to the HA in the registration process. 
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Figure 11. Registration Request Packet 


3. Tunneling 

Encapsulation or Tunneling is used in Mobile IP to deliver packets from a MN’s 
home network to its current point of attachment, which is the CO A or CCOA [PERI]. 
Tunneling enables all external nodes (HAs and FAs) to “see” the same IP address for the 
MN, no matter where its current point of attachment may be. 

Tunneling involves the encapsulation and decapsulation of IP Packets by the node 
agents within the Mobile IP network. Tunneling utilizes IP-in-IP encapsulation to 
correctly route the original packet to its ultimate destination (Figure 12). The original 
packet is encapsulated within the payload of the outer packet. The header of the outer 
packet contains the IP addresses of the source (IP address of HA) and destination (COA). 
These IP addresses are considered to be the tunnel entry point and tunnel exit point, 
respectively. Encapsulation is performed by the sender and decapsulation is performed 
by the receiver. Depending on how the tunnel is set up, the decapsulator could either be 
the FA or the MN. 
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Figure 12. IP-in-IP Encapsulation 


The packet routing procedures used depend on the point of attachment (Home Agent or 
Foreign Agent). If a mobile node is in its home network, sending and receiving data 
packets does not require any special routing method. However, when a mobile node is in 
a foreign network, sending and receiving data packets by the mobile node requires 
several steps. 

When a mobile node is sending packets from a foreign network, it uses its care-of 
address or collocated care-of address to forward the packets. As described by [JAR], 
when a MN is receiving packets (Figure 13), the steps are as follows: 

• A HA on the home link advertises reachability of the mobile node’s home 
address network prefix 

• Packets destined to the mobile node’s home address are therefore routed to 
the mobile node’s home agent. 

• The HA intercepts the packets destined to the mobile node and tunnels a 
copy to the appropriate care-of address that was registered by the mobile 
node. 

• After arriving at each care-of address, the original packet is decapsulated 
and delivered to the mobile node. 
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Figure 13. MN Receiving Packets on a FN 


B. SECURITY CONCERNS IN MOBILE IP 

There are standard security issues that apply to any network, which must be 
considered before going on to concerns in Mobile IP. Security issues such as 
authentication, data privacy and data integrity are common in any system. Weaknesses in 
these areas can be used to create network attacks such as passive eavesdropping, active 
replay attacks, denial of service, and session stealing. The addition of mobility creates 
additional security issues both in allowing a mobile device and connecting it to a network 
by dialing in or physically taking a laptop from one network to another. The security 
threat is that the mobile device can penetrate any network if it is allowed to physically 
enter the network. 

However, for the purposes of this thesis, the idea of mobility will be synonymous 
with the idea of being mobile and wirelessly connected. The use of wireless technology 
brings along additional security issues on top of the standard security ones. Wireless 
technology operates on radio waves. Intercepting radio wave communication signals is 
trivial with the right tools. Sniffer tools such as Sniffer Technologies’ Sniffer Wireless 
Tool and AirSnort from Sourceforge.net allow malicious attackers access to sensitive 
information sent over wireless communication sessions. In the following sections we 
describe these security issues in greater detail. 
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1. Passive Eavesdropping 

Passive eavesdropping involves an attacker using some sort of IP packet sniffer 
such as Ethereal which is available on many systems including Linux, various BSD 
OSes, Solaris, Windows and MacOS X based on the libpcap library [ETH], WebSniff 
[SEC], or Sniffer Technologies’ various sniffer products [SNI], to capture data flow on a 
communication line and wirelessly. Using this method, an attacker viewing unencrypted 
communications can gain information such as user accounts, user names, passwords, 
messages, etc. This is particularly dangerous in a wireless network because the attack 
could happen anywhere, whereas in a wired network, the attacker usually needs physical 
access to the communication lines (and/or bridges or routers), which are used to carry the 
traffic between the communicating parties [SOL]. 

This attack can be prevented using two methods, end-to-end encryption or Low 
Probability of Intercept/ Low Probability of Detection (LPI/LPD). End-to-end encryption 
encrypts and decrypts the data at the source and the destination can be used. This 
encryption provides protection against eavesdroppers because any information that gets 
delivered is encrypted. Therefore, any information that is “sniffed” off of the wireless 
communication link is useless ciphertext to the eavesdropper because it cannot be 
decrypted [SOL], Unfortunately, encryption does not fully protect against traffic 
analysis, which involves identifying usage patterns and the protocols that are being used. 
Adding IPSec (explained later in the thesis) can defend against traffic analysis because 
the attacker will not know where the packets originally came from [NIC]. LPI/LPD 
provides a method that the military uses to send data. One way to accomplish this is to 
transmit the information in very short, (pseudo) randomly spaced bursts. This makes it 
difficult for attackers to find the radio-frequency signals [MEN], 

2. Active Replay Attacks 

An active replay attack is one in which a malicious user can use (parts of a) 
previously recorded session to impersonate a valid user to gain access to a network. In 
the case of a wireless network, this could be done more easily and more covertly than on 
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a wired network because the attacker could perform the attack from anywhere that is 
within the range of the wireless network. 

This type of attack can theoretically be applied to a Mobile IP network. When a 
MN registers with its HA, an attacker can copy the registration request and use it at a 
later time, to “replay” to gain “legitimate” access. If the mobile node uses a collocated 
care-of address, the MN registers directly to the HA (Figure 14). Therefore, the 
malicious user can copy the registration requests with session information and use them 
later to send a counterfeit collocated care-of address with the “replayed” session. This 
allows the attacker to communicate directly to the HA, pretending to be a legitimate 
mobile node of the home network. Although we have not tried to perform this type of 
attack, the tools that were previously mentioned make it seem highly possible. To protect 
against this type of attack, there needs to be mechanisms such as timestamps and nonces 
together to give each packet a unique identifier. If another packet was used with the 
same timestamp and nonce, then the receiver could deduce that the packet was sent from 
a malicious source and deny any services. 
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BADGUY 

Figure 14. Theoretical Active Replay Attack in Mobile IP using CCOA 


3. Denial of Service 

Denial of Service is an attack on a network in which access to resources and/or 
information is purposely prevented by an attacker. This attack makes it impossible for 
the parties to communicate. This is not limited only to wireless networks. This applies to 
any network. It can be performed by one of the following: 

• A large number of packets can be sent to a host, making it impossible for 
the host’s CPU to process all of them. Since the CPU is trying to process 
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all of these packets, it is impossible for an exchange of any useful 
information between the host and a legitimate user [SOL], 

• An attacker can prevent traffic from flowing between the communicating 
nodes [SOL], 

An attacker can theoretically perform this type of attack by capturing information 
during the start of the registration request session (Figure 15). The attacker could 
eavesdrop on the registration requests and receive the IP address of the HA. Then, the 
attacker could flood the HA with spoofed packets, making it unable to provide any 
normal services [SOL]. Spoofed packets are packets whose source address is set as a 
nonexistent address or a valid address; therefore the true source of the packet is unknown 
[SOL]. This makes it difficult to know where the attack came from. Again, although we 
have not tried to perform this type of attack, the tools that are available make this 
vulnerability seem possible. 

A way to foil this type of attack is to use ingress filtering, which enables the 
router to discard packets that enter an interface that is not normally used to forward 
packets [SOL], This does not prevent the attack because packets can still be sent with 
seemingly legitimate spoofed IP packets [SOL], 
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Figure 15. Theoretical DoS Attack on Mobile IP 
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4. Session Hi-jacking 

Session Hi-jacking involves an attacker stealing the established connection of a 
valid user. This enables the attacker to act as if they are the legitimate user while the real 
user thinks that the server is down. The server does not know that the attacker is the one 
that is connected and keeps the communication link going. 

In theory, an attacker can perform this attack in a Mobile IP network by waiting 
for the mobile node to register back to its HA, eavesdrop, flood the mobile node with 
spoofing packets, steal the session by sending packets to the HA that appear to have come 
from the mobile node and finally capture packets destined to the mobile node (Figure 16) 
[DAN], Since this is similar to the passive eavesdropping attack, using end-to-end 
encryption could prevent a malicious user from obtaining any useful information [SOL]. 
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Figure 16. Theoretical Session Hi-Jacking in Mobile IP 


C. DHCP AND SECURE MOBILE IP 


1. DHCP 

One important part of secure Mobile IP is the dynamic host configuration protocol 
(DHCP). Although Mobile IP can be implemented without DHCP, our implementation 
used DHCP to distribute a collocated care of address to the mobile node. 
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Secure Mobile IP requires that the tunnel be encrypted from the mobile node back 
to the HA. MN Decapsulation, in which the MN performs the decapsulation of the outer 
packet to reveal the original packet, allows for this type of implementation. It establishes 
a tunnel from the roaming mobile node to the HA. FA Decapsulation, in which the FA 
performs the decapsulation of the outer packet to reveal the original packet to forward, 
establishes a tunnel from the HA to the foreign agent, which is used as a care-of-address. 
It’s important to note that tunneling always stops at the care-of-address in Mobile IP. In 
MN Decapsulation the mobile node acquires a collocated care-of-address via DHCP, 
which is then used as the care-of-address. This is important since anything coming out of 
the mobile node needs to be encrypted and if the tunnel is only to the foreign agent then 
some one on the same network subnet could be sniffing traffic from the visiting mobile 
node. 

The Internet Engineering Task Force (IETF) created the Dynamic Host 
Configuration Protocol. DHCP is useful in secure Mobile IP (SecMIP) because SecMIP 
requires the use of MN Decapsulation as described in chapter II. DHCP provides a 
means of distributing a collocated care of address to a visiting mobile node. DHCP was 
originally defined in RFC 1531 but the most recent update is RFC 2131. DHCP allows 
for in response to the need of having management of IP addresses on centralized servers 
vice client systems. It was developed from an earlier protocol called Bootstrap 
(BOOTP), which was used to pass information during initial booting to client systems. It 
was designed to store and update static information for clients, including IP addresses. 
The BOOTP server always issued the same IP address to the same client. As a result, 
while BOOTP addressed the need for central management, it did not address the problem 
of managing IP addresses as a dynamic resource [SUN], 

a. What is DHCP 

DHCP is used to assign IP addresses, track their usage and follow their 
traces. This is important for logging especially when there is a security breach, and to 
recover a predetermined list of IP addresses and other configuration information shared in 
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a network of systems. DHCP dynamically assigns IP addresses to hosts that attach 
themselves to networks. Figure 17 is a DHCP leasing sequence timeline [TAR], 


Serai Client Serial 



Figure 17. Messages Exchanged Between DHCP Server and Client. 

Step 1: The client broadcasts a DHCPDISCOVER 

Step 2: Each server may respond with a DHCPOFFER message. 
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Step 3: The client receives one or more DHCPOFFER messages from one or 
more servers and chooses one server from which to request configuration parameters. 
The client then broadcasts a DHCPREQUEST message. 

Step 4: Those servers not selected by the DHCPREQUEST message use the 
message as notification that the client has declined that server’s offer. The server 
selected commits and responds with a DHCPACK message containing the configuration 
parameters for the requesting client. 

Step 5: The client receives the DHCPACK message with configuration 
parameters. At this point, the client is configured. If the client receives a DHCPNAK 
message the client restarts the configuration process. 

Step 6: The client may choose to relinquish its lease on a network address by 
sending DHCPRELEASE message to the server. 

Step 7: The server receives the DHCPRELEASE message and marks the lease as 

free. 

Organizations that support DHCP have at least one or more DHCP servers, which 
maintain a block of IP addresses unique to that organization. In our test bed, we 
implemented DHCP on Linux Redhat 8.0 with the 2.4.18 kernel machines. There are 
different ways of assigning addresses. One can define a block of IP addresses to be 
assigned to clients. One can also assign a specified address to a specified machine . 
There at least a half dozen ways of assigning addresses via DHCP however; we will not 
go into the details in this paper. The DHCP service can be started and restarted in Redhat 
through command line or GUI. When a user boots a client system, that system 
broadcasts a request for a DHCP server to issue it an IP address. The server responds 
with an IP address, gateway, lease time information, etc. The information that the client 
gets is limited to what the DHCP administrator configures in the dhcpd.conf file. 

b. Where DHCP is Useful 

The most common usage of DHCP is to move the management of IP 
addresses away from the distributed client systems and onto one or more centrally 
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managed servers. These central servers maintain databases of network specific 
information (addresses, netmasks, and so on) which relieves the client from having to 
store static network information on their machines Sites that have many TCP/IP clients 
such as NPS would be an environment where DHCP would be useful because it would 
too big of a task for a network administrator to keep track of all these clients. Also, sites 
where laptops commonly move among networks within the site, again much like NPS’s 
wireless network would be candidates for a DHCP implementation. 

Another environment where DHCP would be useful is in secure Mobile 
IP. When the mobile node moves from its home network to a foreign network it acquires 
a collocated care-of-address via DHCP, which is then the care-of-address where the 
tunnel stops. The tunnel goes from the HA all the way to this newly acquired address of 
the mobile node, which is the focus of this thesis will be discussed more in-depth in 
Chapter II and IV. 

D. MOBILE IP VS. MOBILE TELEPHONY 

In table 4 we show the similarities in functionality between mobile telephony and 
Mobile IP. Listed are the mobile functions then a brief description of how Mobile IP and 
mobile telephony deal with the function. 
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Functions 

Mobile Telephony 

Mobile IP 

Communication 

Base station controller, which includes 

Access Point. Communicates 


the base transceiver tower, 

communicates directly with mobile 

phone. 

directly with the mobile node. 

Handoff 

Depends on the technology. It can be 

In Mobile IP, the mobile node 


either hard of soft (discussed in 

performs the handoff. 


previous paragraphs). In CDMA the 

Dynamics breaks the 


phone does the handoff. Other 

connection completely while 


technology such as TDMA the 

MN registers then continues 


network informs the phone. 

connection. Connection 

drops after a few minutes of 

inactivity. 

Location/ 

When the phone powers up it sends 

In Mobile IP the mobile node 

Update 

out its SID (System Identification 

once connected to the foreign 


Number) which is a unique n umber 

agent will send a registration 


assigned to every wireless operator in 

request to its HA, which is 


the US that is then programmed into 

found by the HA address set 


the phone. If it matches then it knows 

in the MN. Once accepted 


it’s at home. If it doesn’t match then it 

the mobile node can begin 


knows it’s roaming. The local MSC 

transmitting and receiving 


communicates with the home MSC of 

the phone and the phone sends a 

registration to its local MSC. Once 

it’s validated then the MSC knows the 

location of the phone and knows 

packets via the HA. 
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where to send its calls. 


Registration 

Registration request is sent to the local 

MSC, which validates or rejects. If 

the phone is not at home the local 

MSC communicates with home MSC. 

Once the phone registers with the 

home MSC the MSC keeps track of 

location in a database. This database 

is the home location register, which 

maintains routing information. 

If the mobile node is at home 

it registers with its HA, which 

either accepts or rejects. If 

it’s in a foreign network the 

mobile node registers with 

the foreign agent, which 

forwards it registration to the 

MN’s HA. The HA then 

keeps track of the MN’s care- 

of-address and forwards 

packets destined for the MN 

to it the MN’s care of 

address. 

Routing 

The public switched telephone 

network, which is, comprised of the 

telephone companies’, routes calls to 

the appropriate destination. 

Since Mobile IP is packet 

based all packets are routed 

over the internet to the 

appropriate destination. 


Table 4. Comparison of Mobile IP and mobile telephony 
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III. DYNAMICS HUT - MOBILE IP IMPLEMENTATION 


We chose Dynamics for our project because of the fact that the source code was 
readily available and it was built on top of Linux. In addition, this implementation had 
the best documentation. On the other hand, only marginal support was available as this 
project has been dormant for nearly three years. We found an active mailing list that was 
somewhat helpful in getting the implementation up and running. 


A. DYNAMICS BACKGROUND 

The Dynamics project began during the academic year of 1998-1999 at Helsinki 
University of Technology offered as a course. Originally, the assignment was to build a 
hierarchical Mobile IP implementation for IPv4 networks [MAL], 

A hierarchical Mobile IP network includes more than one foreign agent in a 
foreign network (Figure 18). These foreign agents comprise the hierarchical structure of 
the network. 
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Internet or Network Backbone 



The goal of this type of structure is to make the distance of the registration 
requests and replies as minimal as possible. The tunnel is established between the HA 
and the highest FA (HFA), between each FA in the path to the lowest FA (LFA), where 
FA decapsulation takes place [FOR]. In FA decapsulation, the end of the tunnel is the IP 
address of the LFA that is connected to the MN. The following sections will describe the 
different system elements and the dynamics of this implementation. 
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B. SYSTEM ESSENTIALS 


This implementation of Mobile IP contains the essential elements of a HA, mobile 
node and a foreign agent. These are all common elements needed in a Mobile IP 
network, according to RFC 2002. However, the Dynamics implementation adds more 
functionality by allowing for a hierarchical structure of foreign agents. 

1. The Home Agent and the Mobile Node 

These two elements have the basic functionality as previously described in 
Chapter 2, section A, entitled, Architecture of Mobile IP?. The HA also has an added 
operation of producing and distributing the session keys needed for regional registrations 
in a foreign network [MAL], It is considered to be the key distribution center for the 
foreign agent and the mobile node [MAL], 


2. The Foreign Agent 

The foreign agent in this implementation allows for regional registration, which 
allows the mobile node to register with all the FAs between itself and it’s HA [PERI]. 
When the MN registers with the LFA in the FA hierarchy, the registration request gets 
relayed to the next higher level FA. For each registration request, each FA stores the 
address of the next lower FA in the hierarchy. That address is determined by the address 
in the request message [PERI], Regional registration limits the effect of latency over 
congested links and remote hosts [MAL], Each time the mobile node changes is position 
in the foreign network, the first agent advertisement that it receives from a FA will be 
considered as the closest to the MN. When the MN sends out a registration request, that 
request goes to the FA closest to the MN. The registration request is forwarded up the 
hierarchy to another foreign agent until it reaches the highest FA, HFA. The HFA then 
forward the registration request to the HA. The reply message from the HA will take the 
same path through which the request came from. 
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c. 


TUNNELING/ROUTING 


In this implementation of Mobile IP, the establishment of the tunnel occurs 
between the home agent (HA) and the current registered location of the mobile node 
(MN). Depending on which decapsulation method is used, the tunneling will differ. If 
FA decapsulation is used, then the tunnel is created from the HA to the FA (Figure 13). 
In the case of a hierarchical structure, the tunnel is created between the HA and the FA 
and between each FA all the way down to the lowest foreign agent [FOR] (Figure 19). 



Figure 19. Tunnel Representation in Hierarchical FN (FA decapsulation) 

In the case of MN decapsulation, the tunnel is directly created between the HA 
and the MN (Figure 20). This last method allows the mobile node and the HA to 
communicate directly with each other through this tunnel. 
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Figure 20. Tunnel Representation for MN Decapsulation 


Dynamics uses the IP-in-IP and Generic Record Encapsulation (GRE) 
encapsulation modules. GRE is more of a general protocol compared to IP-in-IP because 
it can encapsulate other protocols other than IP [PERI], For the purpose of this thesis, 
we chose to use the default protocol IP-in-IP for simplicity. 

The tunnel that is created is represented in the Linux operating system as another 
interface that can be referenced in the same way as a physical Ethernet interface such as 
ethl or ethO. The endpoints of the tunnel are the HA and the care-of address. For FA 
decapsulation, the name of the tunnel has the format TUNL with a number appended to 
the end, with the starting number at 0. In our implementation, we only had one tunnel up 
at a time so the name of our tunnel in FA decapsulation mode was always TUNLO. In 
MN decapsulation, the standard name of the tunnel is TUNLMNA. 

D. POLICY-BASED ROUTING 

Dynamics routing is based on policy routing in Linux [FOR]. Policy routing 
protocols share the idea that one route should be selected out of all available routes to 
minimize some measure of the route, such as, delay [CLA], Policy-based routing uses 
both the source and destination addresses to correctly route packets [MAR], To correctly 
route packets to MN, the FAs in the hierarchy must know the ultimate destination as well 
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as the packet origin [MAL]. In a large FA hierarchy with many different paths, policy- 
based routing is needed for the FAs to choose the correct path to route the packets and 
minimize delay. For a more detailed description of policy routing and policy-based 
routing please refer to [CLA] and [BRA], For more information on policy-based routing 
in Linux please refer to [MAR], 


40 



IV. WIRELESS SECURITY 


As we have discussed, the use of wireless devices has grown exponentially, which 
means that the amount of information traveling over the air has increased. Now with the 
invention of Mobile IP, security is an even bigger technical problem because Mobile IP 
allows for roaming of mobile devices which means there will be much more sensitive 
information such as business information, personal credit card numbers, or social security 
numbers more easily accessible in the air. In this section we will cover some of the 
wireless security issues. We will start out by covering the Wired Equivalent Privacy 
(WEP) algorithm [ISA]. Next we will discuss the use of IPSec, and lastly IPSec 
integrated with for Secure Mobile IP to create secure Mobile IP and its’ advantages and 
disadvantages. 

A. WEP 

It is common in schools and business to have 802.11-based wireless local area 
networks (WLANs). A WLAN allows a user to connect to a local area network through a 
wireless (radio) connection. The IEEE 802.11 standard specifies technologies for LANs. 
It uses the WEP (Wired Equivalent Privacy) algorithm for encryption. While WEP 
provides some level of security for WLANs there are security issues concerned with 
WEP that make WLANs that use WEP, vulnerable to various types of attacks. [NIC], 

WEP can be used to help prevent passive eavesdropping and provide some level 
of authentication. The goal of the WEP model is to prevent casual eavesdropping or 
unauthorized data modifications [NIC], 

However, there are security flaws associated with WEP, which make WEP 
practically unusable for organizations that require privacy. Because an eavesdropper can 
sniff packets while attached to a wired network, there may need to be other mechanisms 
for encrypting and authenticating mobile users. 

WEP protects only the data packet information and does not protect the physical 

layer header so that other stations on the network can listen to the control data needed to 

manage the network [NIC]. An attacker could easily analyze the traffic and after about 5- 
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6 MB of data can have enough information to have a key. For these reasons we don’t 
believe that WEP would be a solution to privacy for a mobile device. 


WEP uses a secret key that is shared between a wireless station and an access 
point (AP). WEP uses an RC4 40-bit or 64-bit stream cipher from RSA Data Security to 
encrypt and decrypt data. The 32-bit CRC (Cyclic Redundancy Check) is also encrypted 
along with the frame body [GDB], Figure 21 [GDB] shows a WEP packet. 


M RC4 encrypted ^ 


IV 


Payload 


CRC-32 


Figure 21. Packet Format [GDB] 


CRC is a technique to obtain data integrity. It has three significant advantages: 
error detection capabilities, little overhead, and ease of implementation [RAD], 
According to the ISAAC (Internet Security, Applications, Authentication and 
Cryptography), the WEP algorithm can be broken through various attacks [BOR2], which 
will be discussed in the following paragraphs. ISAAC is a small research group in the 
Computer Science Division at the University of California, Berkeley. According to this 
paper WEP is susceptible to the following: 

• passive attacks to decrypt traffic based on statistical analysis 

• active attack to inject new traffic from unauthorized mobile stations based 
on known plaintext 

• active attacks to decrypt traffic based on tricking the access point 

• dictionary-building attacks 

1. Passive Attacks to Decrypt Traffic Based on Statistical Analysis 

This attack is based on collecting information over a period of time and using the 
information to perform an attack. We like to compare this to social engineering. A 
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passive eavesdropper can intercept all wireless traffic, until an Initialization Vector (IV) 
collision occurs. By XORing two packets that use the same IV, the attacker obtains the 
XOR of the two plain text messages, which enables the attacker to perform statistical 
attacks to recover the plaintexts [ISA]. The resulting XOR can be used to infer data to 
gain information on the contents of the two messages. IP traffic is often very predictable 
and includes a lot of redundancy due to the initialization vector [ISA], The initialization 
vector in WEP is a 24-bit field, which is sent in the cleartext part of a message. A 24-bit 
field initialization vector guaranteed the reuse of the same key stream. A busy access 
point, which constantly sends 1500 byte packet at 11Mbps, will exhaust the space of IVs 
after 5 hours [ISA], This redundancy can be used to eliminate many possibilities for the 
contents of messages. This gives an attacker many possibilities get at the data in the 
messages. Further educated guesses about the contents of one or both of the messages can 
be used to statistically reduce the space of possible messages, and in some cases it is 
possible to determine the exact contents. When such statistical guessing doesn’t work, 
the attacker can just look for more collisions of the same initialization vector. With just a 
small amount of time, depending on the situation, it is possible to recover a modest 
number of messages encrypted with the same key stream, and the success rate of 
statistical analysis grows quickly. Once it is possible to recover the entire plain text for 
one of the messages, the plain text for all other messages with the same IV follows 
directly, since all the pairwise XORs are known [BOR2], 


2. Active Attack to Inject Traffic 

If an attacker knows the exact plaintext for one encrypted message, he can use 
this knowledge to construct correctly encrypted packets. The procedure involves creating 
a new message, calculating the CRC-32, and performing bit flips on the original 
encrypted message to change the plaintext to the newly created message [BOR2]. The 
basic property is that RC4(X) xor X xor Y = RC4(Y) [BOR2], This packet can now be 
sent to the access point or mobile station, and it will be accepted as a valid packet. 
[BOR2] 
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3. 


Active Attack from Both Ends 


This is just an expansion of the previous attack. It can be expanded further to 
decrypt arbitrary traffic. In this case, the attacker makes a guess not about the contents, 
but rather the headers of an IP packet. This information is usually quite easy to obtain or 
guess; in particular, all that is necessary is the destination IP address. Armed with this 
knowledge, the attacker can flip appropriate right bits to transform the destination IP 
address to send the packet to a machine he/she controls, somewhere in the world of the 
internet, and transmit it using a rogue mobile station. Most wireless installations have 
Internet connectivity; the packet will be successfully decrypted by the access point and 
forwarded unencrypted through appropriate gateways and routers to the attackers 
machine, revealing the plaintext. If a guess can be made about the TCP headers of the 
packet, it may even be possible to change the destination port on the packet to be port 80, 
which will allow it to be forwarded through most firewalls. [BOR2] 

4. Dictionary-building Attack 

The dictionary-building attack allows, after analysis of about 5-6 MB of 
traffic, real-time automated decryption of all traffic. An experiment performed by three 
students at Rice University showed that 5-6MB of packets is enough data to find the key 
[STU]. With a small number of initialization vectors an attacker can build a decryption 
table. Once he/she learns the plaintext for some packet, he/she can compute the RC4 key 
stream generated by the IV used. This key stream can be used to decrypt all other 
packets that use the same IV. Over time an attacker can build up a table of IV’s and 
corresponding key streams. Armed with this table, an attacker can decrypt every packet 
that is sent over the wireless link [BOR2], 

B. IPSEC 

IP Security (IPSec) is a set of open standards developed by the EETF and 
documented in Internet general Request-For-Comments (RFC 2401) and related RFCs. 
The following is the IPSec protocol suite RFCs. The three main components of IPSec are 
AH, ESP, and IKE. 
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• Internet Key Exchange - RFC 2409[ITF] 

• IP Authentication Header - RFC 2402[ITF] 

• IP Encapsulating Security Payload (ESP) - RFC 2406[ITF] 

• Security Architecture for the Internet Protocol - RFC 2401 [ITF] 

• Internet Security Association and Key Management Protocol - RFC 
2408 [ITF] 

• The Internet IP Security Domain of Interpretation for ISAKMP - RFC 
2407[ITF] 

IPSec provides for end-to-end encryption and authentication at the IP layer to 
protect IP packets between IPSec-compliant devices. IPSec is currently supported in 
IPv4 and IPv6. IPSec is most commonly found in network devices such as router, 
switches, firewalls, and remote access servers as well as many clients as part of VPN 
solutions. Some of the services offered by the IPSec protocol suite include: Access 
control, Connectionless integrity, Data origin authentication, Protection against replays. 
Confidentiality (encryption), and Limited traffic flow confidentiality. These services use 
transmission protocols, IP Authentication Header (AH) and IP Encapsulating Security 
Payload (ESP), together with one of the available key management protocols [NIC]. 
The following paragraphs will cover IPSec in more detail. Before doing so we believe it 
is important to cover two fundamental aspects of IPSec: Security Associations (SA) and 
Tunneling. These two concepts are not new to IPSec, but IPSec makes use of them. 

A Security Associations (SA) is a unidirectional, logical connection between two 
IPSec systems. The Security Association is identified by a security parameter index, IP 
destination address, and security protocol [MUR]. The security parameter index is a 32- 
bit value used to identify different SAs with identical destination address and security 
protocol. For bi-directional communication between two IPSec systems, there must be 
two SAs defined, one in each direction. 

Tunneling is a common technique in packet-switched networks. It is basically the 

concept of wrapping a packet inside a new one. This makes it possible to route the 

nonroutable such as NetBIOS, IPX or, specific to this thesis, private IP addresses. In the 
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case of IPSec, IP packets are tunneled through IP to provide security thereby avoiding 
malicious attacks [MUR]. The following points will cover the different aspects of IPSec 
in greater detail. 

1. Internet Key Exchange (IKE) 

In order for hosts to create the secure tunnels that make up a VPN, they must 
create secure associations, authenticate each other, and exchange the keys they will use 
for the encryption for their data. One way of accomplishing this is with the Internet Key 
Exchange (IKE) protocol. IKE is responsible for providing authentication of all peers, 
handling the security policy negotiations, and controlling the exchange of keys [SCT]. It 
is used to create an initial encryption session, enabling the exchange of the information 
required to make the final encryption session. 

This protocol uses parts of ISAKMP and parts of the Oakley and SKEME key 
exchange protocols to provide management of keys and security associations for the 
IPSec AH and ESP protocols, and the ISAKMP itself [MUR], The IKE inherits its 
security association (SA) and key management (but not key exchange) from the ISAKMP 
protocol, and supports the pre-shared key, digital signature, and public key encryption 
methods of authentication. Oakley was originally the key exchange protocol used for 
VPNs and lent its abilities to IKE. Oakley is vital to security, since no matter how strong 
the encryption and authentication algorithms are, they are worthless if the key is 
compromised [MUR]. 

IKE is performed in two phases. In phase one, two hosts establish a secure 
connection, called the IKE SA. Authentication is either incorporated into phase one with 
digital certificates, or takes place between phases one and two with extended 
authentication techniques (Bird, pp. 89-90). In phase two, the final keys used for 
encryption will be generated, and the IPSec SA will be negotiated. After these two 
phases, the IPSec SA has been created and is used for all further communication, creating 
the secure “tunnel.” 

In the first phase, IKE chooses between two modes to complete the IKE SA: 
Main mode and Aggressive mode. During the second phase, IKE uses its third mode, 
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Quick mode, to negotiate the final IPSec SA. If extended authentication is required, 
another step is inserted between these two to authenticate the user. 

a. Main Mode 

To create an IKE SA, Main mode will take the two hosts through three 
two-way exchanges, totaling six steps. In the first exchange, steps one and two, the hosts 
agree on basic algorithms and hashes that will be used throughout the remaining four 
steps. In steps three and four, they prepare to create an encrypted tunnel by using the 
Diffie-Hellman key agreement, exchanging the necessary items to create their shared 
secret key. If the two sides have digital certificates then these are also exchanged [YJL], 
Steps five and six complete the Diffie-Hellman exchange, leaving each with the shared 
secret, which is used to encrypt the rest of the communication [TIM], 

b. Aggressive Mode 

This mode is used to accomplish the same end result as Main mode, but it 
does so in only three steps instead of six. This mode is quicker, but at the sacrifice of not 
protecting the identity of each host. In main mode, host identities are not normally 
divulged until the encrypted fifth and sixth steps of Main mode. 

Aggressive mode is accomplished by sending the IKE SA proposal, the 
Diffie-Hellman information, digital certificates if used, and the ID packet all in the initial 
exchanges between the two hosts during steps one and two, instead of breaking them 
down into six steps. The last step of this mode is just a confirmation exchange [TIM], 


c. Extended Authentication (XAUTH) 

If the hosts choose not to use digital certificates to authenticate each other, 
then authentication must take place before continuing on to phase two, Quick mode. In 
Extended Authentication mode an extra set of exchanges takes place between the hosts to 
authenticate each other using an extended authentication method such as RADIUS 
[YKL], RADIUS is a protocol for exchanging information between a RADIUS server 
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and a RADIUS client. Its main purpose is to provide authentication, authorization, and 
accounting for remote access users when they connect to a network. 


d. Quick Mode 

Quick mode is used in phase two to negotiate the final IPSec information 
between the now-authenticated and secure hosts. This is accomplished using the current 
IKE SA to ensure security of the exchange. The end result of this phase is the creation 
of the final IPSec SA and the generation of fresh keying material, including the 
symmetric key used for all further encryption between the hosts. 

To generate the new SA, the initiating host sends the Quick mode 
message, protected by the IKE SA, requesting the new IPSec SA. This request includes 
which Security Parameter Index (SPI) to use in future communications. This SPI, 
combined with the destination IP address and protocol to be used, uniquely identifies a 
single IPSec SA. It is important to remember that these SAs are only for one-side of the 
conversation. As we mentioned earlier SAs are unidirectional therefore it takes two SAs 
for bi-directional communication. 


e. Perfect Forward Security (PFS) 

PFS is an option in generating the final set of symmetric keys in Quick 
mode. The goal of PFS is provide the confidence that the compromise of a long-term 
private key does not compromise any earlier session keys [YMJ], It is used to create a 
key that does not have any information derived from or depending on the previous key 
used. 

When the final keys are to be created, there are two ways this can be done. 
Quick mode can be set to create the new key by just hashing the original key used during 
IKE phase one. Though this is simple and fast, the problem is that if the original key is 
later cracked, it is a simple step to hash that cracked key, giving the cracker the next key. 
To keep this from happening, Quick mode can use PFS to initiate a new Diffie-Hellman 
key exchange. This use of Diffie-Hellman ensures that even if the original key is 
cracked, it gives no information on the next key. The cracker would then have to go back 
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and crack the new key instead of just being able to hash the previous key value to find the 
new key. The down side to this is that it takes more time, steps, and computational power 
to create new keys using Diffie-Hellman algorithm then it does to just hash the previous 
one, so security needs to be balanced with threats to meet each individual communities 
needs [TIM], 


f. Security Associations (SA) 

In the previous sections we used the term security association, SA, 
because this is such an important part of IPSec we feel it is important to discuss a security 
association. 

A SA is a logical security connection between two IPSec systems. SAs 
are negotiated when IPSec hosts create their connection, and take the form of 

<Security Parameter Index, IP Destination Address, Security Protocol> 

The Security Parameter Index (SPI) is a unique 32-bit value used to 
identify the SA. It is carried in the header of the security protocol, and selected by the 
destination system during SA establishment. When the SA is established, the 32-bit SPI 
value is chosen by the destination system [MUR]. 

The Security Protocol is either ESP or AH, which will be discussed in the 
following sections. SAs define a security association in only one direction, to the 
destination. Since communication is often a bi-directional activity, two SAs must be 
established during an IPSec session, one in each direction [MUR]. 

It is possible to use both ESP and AH together, but in order for this to 
happen an SA bundle is created. SA Bundles are two SAs defined in each direction, 
establishing a total of four SAs for the IPSec session. This is seen most often when a 
mobile host needs to create an AH SA between itself and the network gateway, and a 
nested ESP SA extends to the host behind the gateway [MUR]. 
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2. Authentication Header (AH) Protocol 

The Authentication Header Protocol is defined in RFC 2402. AH guards against 
denial-of-service attacks, but does not provide confidentiality. It provides integrity and 
authentication for IP datagrams. These services work on a per-packet basis to ensure 
protection on each and every packet thereby protecting the entire flow of information. 
Some fields are not protected by AH these are called mutable. However, the payload of 
the IP packet is considered immutable and is always protected. 

When packets arrive at intermediate routers, the packet is first authenticated 
before being sent it its final destination. AH can be used in both transport and tunnel 
mode. Since tunnel mode is specific to our thesis we will cover how AH is used in tunnel 
mode. 

A new IP header is applied to the original IP packet. Next, the authentication 
header is applied in front of the original packet but after the new IP header. The new IP 
header is stripped, the AH authenticates then original destination IP address and finally 
the packet is reassembled and forwarded on to its destination. 

AH can be used in tunnel mode or transport mode [MUR]. The following 
diagrams, Figure 22 and Figure 23, show AH in tunnel mode and transport mode, which 
were acquired from the Murhammer reference on pages 54-61. 
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Figure 22. Authentication Header in Transport Mode 
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Figure 23. Authentication Header in Tunnel Mode 
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3. Encapsulating Security Payload (ESP) 

The Encapsulating Security Payload is defined in RFC 2406. It offers 
authentication, integrity, and replay protection. Unlike AH, ESP provides confidentiality. 
The set of desired services is selected upon negotiation of the security association (SA). 
ESP is performed on each individual packet, on a per-packet basis. Both the integrity and 
encryption aspects are optional, and the administrator can choose to implement either or 
both. If both are selected, the receiver of the packet must first authenticate the packet, 
and only if it authenticates, will the packet be decrypted. Integrity check and 
authentication methods must be chosen so that they complement each other. The 
encryption algorithm used is independent of whatever choice is made for integrity and 
authentication. ESP can be used in transport mode (Figure 24) or tunnel mode (Figure 
25) [MUR], 
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Figure 24. ESP in Transport Mode [MUR] 
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Figure 25. ESP in Tunnel Mode [MUR] 
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4. Transport Mode 

Transport mode is used for transmitting data between two hosts. Only the data is 
encrypted (Figure 26). An IPSec header is placed before the payload (data), but after the 
original IP header. This is best used in an internal network where source and destination 
IP addresses are not of vital importance. To protect that kind of information one would 
use tunnel mode. 
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Figure 26. IP Data Packet [YNJ], 

5. Tunnel Mode 

Tunnel mode is used when transmitting data between two security gateways such 
as two routers. Tunnel mode is needed to secure Mobile IP because there are many 
foreign networks the mobile node can join. Therefore it is necessary to protect the 
packets as they go through each intermediate router and to keep knowledge of the home 
network hidden from the public. This mode was implemented in our thesis. 
Implementation details are discussed in the implementation chapter. 

Figure 25is a visual picture of what goes on with tunnel mode. The sending 
gateway encrypts the entire IP packet and appends a new IP header that includes the 
receiving gateways address as the destination address. When the receiving gateway 
receives the packet, it strips off the outer IP header, decrypts the packet, and sends the 
packet to the final destination. 
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This configuration is typically referred to as a Virtual Private Network (VPN) 
[NIC], It would not be possible for one to see the source or destination address since this 
information is hidden. This is the preferred choice when using private, non-routable 
addresses over a wide area network [NIC]. 

B. IPSEC IN MOBILE IP 

One of the problems with Mobile IP is the firewall traversal problem. Access to a 
virtual private network is granted only to authorized users. This section describes how 
IPSec is used with Mobile IP to provide Mobile IP users secure access to their company’s 
firewall protected virtual private network. Mobile nodes that belong to an organization 
have to traverse the firewall to access the VPN. Therefore, they have to authenticate 
themselves. This authentication is realized with IPSec. Secure Mobile IP (SecMIP) uses 
an IPSec tunnel to protect the Mobile IP tunnel passing the insecure parts of the Internet. 
Figure 27 [DAN] further illustrates the idea behind SecMIP tunneling. 
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Figure 27. SecMIP Tunneling 

After entering a new network area, a mobile node has to be connected via a 
wireless access point. Foreign agent advertisements are broadcasted regularly into this 
demilitarized zone (DMZ), which is a network or computer host between a private 
network and the outside public network that prevents outside users direct access to data 
on a private server.. The mobile node learns about its physical change of location when it 
receives this ICMP message. Figure 28 [DAN] illustrates network detection. 
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Figure 28. Network Detection 

When the mobile node enters the new network it disables any old IPSec tunnels 
that had been established from an older locations using an old collocated care-of-address. 
The mobile node then needs to acquire a new collocated care-of-address through a DHCP 
server or from a foreign agent and finally a tunnel is established. Once the IPSec tunnel 
is established, data transfer is secured. The IPSec tunnel will be between the mobile 
node’s new care-of-address and the home firewall. Figure 29 [DAN] further illustrates 
the IPSec tunnel between the MN and the home firewall. 



Figure 29. IPSec Tunnel MN O Home Firewall 
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V. IMPLEMENTATION 


For our implementation, we used the Dynamics HUT Mobile IP implementation 
to set up the Mobile IP network. The version that we used was 0.8.1, which is the most 
up to date, stable release. Our setup consisted of the following hardware items: 

• 2 Linksys WAP11 Access Points 

• 2 Dells Dimension 8200 

• 4 Netgear DS108 Hubs 

• 1 Micron Millennia, Linux Router/Gateway 

• 1 Gateway 9100 Solo Laptop 

A. MOBILE IP NETWORK ARCHITECTURE 

Our initial goal was to create a configuration to see how the Mobile IP 
implementation works (Figure 30). We based our configurations based on the project 
conducted by Yan, Zan, et al. [YAN], In the next sections, the configurations for each 
piece of hardware will be explained. We tried to simulate two subnets and the seamless 
handoff between them. 
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Figure 30. Initial Mobile IP Setup 

1. Agents 

The configurations for both the home agent and the foreign agent are very similar. 
The following configurations are for both of the agents: 

• Pentium 4, 2.3 GHz, 40 Gig HD, 512 MB RAM 

• Redhat Linux 8.0, kernel version 2.4.18-14 

• Two NIC cards: 

o 1 Realtek RTL-8139, SMC EZ Card and 
o 1 3Com 3c590/3c595/3c90x 

Both agents had the Dynamics implementation installed on them. Each used their 
respective code to start running. For instance, the code for the Foreign Agent was located 
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in “/root/dynamics-0.8.1/src/fa/” directory. This would be the same for the Home Agent 
except that the end of the directory would be “ha” instead of “fa”. The documentation 
was located in “/root/dynamics-0.8.1/doc/” directory. The executables for each agent was 
located in “/usr/local/sbin/” directory. There the “dynfad”, “dynhad”, “dynmn”, 
“dynfa_tool”, “dynha_tool”, and “dynmn_tool” executables are found. 


2. Mobile Node 

The configuration for the Mobile Node is as follows: 

• Pentium 3, 500 MHz, 128 MB RAM 

• Redhat Linux 8.0, kernel version 2.4.18-14 

• One Wireless NIC Card [Linksys Ver 3] 

• One NIC (for wired test) Card - D-Link DFE-680TXD 

3. Gateway/Router 

The gateway/router performed as a transparent medium between the two subnets. 
It forwarded all packets to the destinations according to its routing table. The 
configuration for the gateway/router is as follows: 

• Micron Mellennia, Pentium II 

• Redhat Linux 7.x 

• 2 NIC Cards (Both 3Com 3c590/3c595/3c90x) 

o ethO: 10.3.1.100 
o ethl: 10.3.2.100 

The gateway/router needed to have “ipchains” turned off in order for it to be 
transparent (see Problems). The command ‘ipchains’ in Redhat Linux contains code with 
rules to manage IP packet filters in firewalls [LIN2], For this implementation, we needed 
to turn off packet filtering to allow every packet to pass through the router, making it 
transparent. For detailed information on ipchains, please refer to [LIN2], 
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4. 


Access Points 


The two access points are connected to the home network and the foreign 
network. The API is connected to the home network and the AP2 is connected to the 
foreign network. Please see Figure 30 for the IP addresses. The models of the APs are as 
follows: 

• 1 Linksys WAP11 2.4GHz (API), IP Address: 10.3.4.20 

• 1 Linksys WAP11 (AP2), IP Address: 10.3.3.20 


B. CONFIGURATIONS 

The next subsections will explain the different configurations for each agent, the 
mobile device and the router/gateway. For the agents and router/gateway, we issued the 
commands: 


• echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter 

• echo 0 > /proc/sys/net/ipv4/conf/ethl/rp_filter 

• echo 1 > /proc/sy s/net/ip v4/conf/eth0/proxy_arp 

• echo 1 > /proc/sys/net/ipv4/conf/ethl/proxy_arp 

We also had to change the parameter “net.ipv4.ip_forward” in the file 
“/etc/sysctl.conf” to equal 1. This allowed all packets to be forwarded between the two 
interfaces on the agents and the router/gateway. 


1. Home Agent 

The following configurations for the home agent are: 
• IP Addresses 

o EthO: 10.3.1.1 
o Ethl: 10.3.4.100 


60 



• In the “dynhad.conf ’ file located in /usr/local/etc, we made changes to the 
following parameters: 

Each interface has four parameters associated with it. Ha_disc determines 
whether or not to allow dynamic home agent discovery. A ‘0’ does not allow dynamic 
HA discovery. AH’ allows dynamic HA discovery with broadcast messages. We chose 
ethl since this was the mobile node’s home network. Agentadv has three options: ‘O’, 
‘1’, or ‘-1’. A ‘0’ tells the interface not to send agent advertisements without agent 
solicitation. AH’ sends agent advertisements regularly, which is what we chose because 
we wanted the home agent to constantly send out advertisement so we could debug. A 
1’ does not send any agent advertisements (even solicited). Force_IP_addr is the local 
address to be forced for this interface. By not using this parameter the primary address of 
the interface is used by default. 

INTERFACES_BEGIN 

#interfaces ha_disc agentadv interval force_IP_addr 
ethl 1 1 10 

INTERFACES_END 

The network access identifier is a unique identifier for the home agent. This is 
needed if private address space is used in the home network, which was the case in our 
thesis. 

NetworkAccessIdentifier “test” 

Triangle tunnel means that the packets to the mobile nodes are sent via the home 
agent, but packets from the mobile node are routed directly to the destination. We set this 
to false because it is not possible to use triangle and reverse concurrently. The problem 
with triangle tunneling is that since all packets from the mobile node are routed directly 
then if the mobile node tries to communicate with a node in its home network most 
firewalls will reject those packets. 

EnableTriangleTunneling FALSE 
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Reverse tunneling means bi-directional tunneling in which both the sent and 
received packets from the mobile node are sent via the home agent. The home agent 
intercepts all packets destined to and from the mobile node and forwards them on to their 
destination. We used reverse tunneling since this is what Secure Mobile IP requires 
because all packets to and from the mobile node are handled by the HA. 

EnableReverseTunneling TRUE 

This is the list of MNs that our HA accepts with a unique SPI number of 1000. 
The SPI is the key identifier for the MN. 

ATITHO RT 7EDT IST REGIN 

1000 10.3.4.6 

AUTHORIZEDLIST_END 


2. Foreign Agent 

The following configurations for the foreign agent are: 

• IP Addresses 

o EthO: 10.3.2.1 
o Ethl: 10.3.3.100 

• In the “dynfad.conf ’ file located in /usr/local/etc, we made changes to the 
following parameters: 

This parameter shows the interfaces that are used for Mobile IP services. The 
“interfaces” column is the name of the interface(s) that is being used. The column “type” 
could be one of the following: 

1 = both upper and lower direction 

2 = only upper direction (to upper FA/HA) 

3 = only lower direction (to lower FA/MN) 
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We decided to have interface ethO communicate in both directions and have ethl only 
send data to the MN. This allowed us to receive data packets from the HA on ethO and 
forward them to interface ethl, who forwarded them on to the MN. The column 
“agentadv” is used to define whether or not agent advertisements should be sent on the 
interfaces. We left them to be 1, which indicates to send agent advertisements regularly. 
The column “interval” defines the number of seconds to wait between two agent 
advertisements. We set this to be 10 to allow for faster detection of attachment point by 
the MN. The “force_IP_addr” column is used to define a local address for the interface. 
We did not need to do use this option so we left it blank. By doing this, the primary 
address of the interface was used. 

interfaces_begin 

#interface type agentadv interval force_IP_addr 

ethO 1 1 10 

ethl 3 1 10 

INTERFACES_END 

The “NetworkAccessIdentifier” parameter is used as the unique identifier for the 
FA. This can be any string. For simplicity, we chose the string “test”. 

NetworkAccessIdentifier “test” 

The “HighestFAIPAddress” parameter is used as the IP address of the HFA or 
FA, used to communicate with the HA. For our implementation, we had this set to be 
ethO, which was 10.3.2.1. 

HighestFAIPAddress 10.3.3.100 

This parameter defines whether or not FA Decapsulation is being used. For our 
first trial implementation, we used FA Decapsulation. 

EnableFADecapsulation TRUE 

The parameter “EnableTriangleTunneling” defines how the packets are routed. If 
this is enabled, then packets sent to the MN are sent through the HA, but packets from the 
MN are routed directly to their destination. For our trial implementation, we did not want 
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to use Triangle Tunneling because we wanted to create a tunnel between the FA and the 
HA, causing all traffic to flow between them. 

EnableTriangleTunneling FALSE 

This parameter is used for bi-directional tunneling, which means that packets to 
and from the MN are sent through the HA. This allowed us to create the tunnel between 
the HA and the FA. 

EnableReverseTunneling TRUE 


The steps that we took to start the foreign agent are: 

• Run the setup script, “/usr/local/sbin/dynamics-fa-setup” 

o Enables the user to set parameters such as HighestFA IP address 
and what type of tunneling to use. Those values are written into 
the file “dynfad.conf”. 

• Run the command, “/usr/local/sbin/rsakeygen 728” 

o This command generates a RSA key and stores it in a file. It is 
used to generate keys for FAs, to use in authentication. 

• Run the foreign agent daemon, “/usr/local/sbin/dynfad —fg —debug” 

o This allows the foreign agent to run in the foreground in debug 
mode. 

• Run the foreign agent tool, “/usr/local/sbin/dynfa_tool” 

o This is a tool that has command line user interface that shows the 
status of the Mobile IP service. Commands within the user 
interface such as “tunnels” and “st” allow users to see if there any 
tunnels were created and update the status of the service. 

Once we had the tool up and running, we used the command “st 1” to get a 
constant update of the parameters such as “tunnels”, “request accepted”, “request 
rejected”, which were the most important parameters to check. We were looking for the 
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“tunnels” parameter to change from 0 to 1 and we were also looking for the “request 
accepted” parameter to increase. Once we saw that these certain parameters were 
changing, we were able to assess that the implementation was working. 


3. Mobile Node 

The following configurations for the mobile node are: 

• IP Address: 10.3.4.6 

• In the “dynfad.conf ’ file located in /usr/local/etc, we made changes to the 
following parameters: 

The mobile node’s IP address in the home network. 

MNHomelP Address 10.3.4.6 

The IP address of the mobile node’s home agent. 

HAIPAddress 10.3.4.100 

The home agent network access identifier (NAI) is used to match the HA agent 
advertisements when a MN is determining whether it is at home or not. This is mainly 
used with private HA addresses. 

HANetworkAccessIdentifier “test” 

This enables the foreign agent to decapsulate the IP-within-IP encapsulated IP 
packets. If this is set to false then the mobile node decapsulates the IP packets. In secure 
Mobile IP MN Decapsulation is required as described in chapter II, the Mobile IP 
chapter. 


EnableFADecapsulation TRUE 

The HomeNetPrefix is the network address of the home network. 


HomeNetPrefix 10.3.4.0/24 
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This selects the tunneling mode to be used. A 1 is automatic, but prefer reverse 
tunneling, a ‘2’ is automatic, but prefer triangle tunnel, a ‘3’ accepts only reverse tunnel 
and ‘4’ accepts only triangle tunnel 


TunnelingMode 4 


C. ARCHITECTURE OF MOBILE IP WITH IPSEC 

The implementation with IPSec did not involve dramatic changes (Figure 31). 
The only changes we made to our set up are as follows: 

• Both the Home Agent and Foreign Agent are now configured to be DHCP 
Servers. The home agent gives out addresses in the range 10.3.4.25 - 10.3.4.50. 
The foreign agent gives out addresses in the range 10.3.3.25 - 10.3.3.50. 

• The Mobile Node is set up as a DHCP client instead of having a static address. 
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Figure 31. Network Setup with DHCP and IPSec 

We also had to make changes to the configuration files. Those changes are as 
follows: 

• Home Agent 

o In the “dynhad.conf ’ file, we changed the following parameters: 

We needed to have reverse tunneling in order to create the tunnel between the MN 
and the HA. Triangle tunneling does not allow us to do so. Therefore, we set this 
parameter to be FALSE. 

EnableTriangleTunneling FALSE 
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Enables a tunnel to be created between the MN and the HA. Communication will 
be able to flow directly between the two, which is needed for IPSec tunnel to be used 
with this implementation. 

EnableReverseTunneling TRUE 


• Foreign Agent 

o In the “dynfad.conf ’ file, we changed the following parameters: 

By using IPSec within Mobile IP, the tunnel needs to be established between the 
MN and the HA. Therefore, MN Decapsulation is needed for this implementation. This 
allows communication directly between the MN and the HA. The IPSec tunnel will 
provide the security of communication between the HA and MN. 

EnableFADecapsulation FALSE 

Triangle Tunneling does not enable the tunnel to be established between the MN 
and the HA. Therefore, we set this parameter to FALSE. 

EnableTriangleTunneling FALSE 

Reverse Tunneling allows the tunnel to be established between the MN and the 
HA. With this parameter set to TRUE, all communication to and from the MN goes 
through the HA. 

EnableReverseTunneling TRUE 


• Mobile Node 

o In the “dynmnd.conf ’ file, we changed the following parameters: 

MNHomelPAddress 10.3.4.25 # which was the DHCP assigned address 

FA Decapsulation does not work with what IPSec was providing. In order for the 
MN to decapsulate the packets, we had to set this parameter to FALSE. This allows 
direct communication between the MN and the HA. 


68 



EnableFADecapsulation FALSE 


This parameter means that the MN will only accept reverse tunneling. This 
allows the MN to directly communicate with the HA. Reverse tunneling allows the MN 
to create a tunnel with the HA. To implement IPSec with this implementation, direct 
communication between the HA and the MN is essential. 

TunnelingMode 3 


1. IPsec Implementation 

In order to implement setup Secure Mobile IP with dynamics on a Linux machine, 
it is necessary to use an IPSec implementation. For this we decided to research 
FreeS/Wan, which is free and the source code is provided [LIN1], FreeS/Wan stands for 
“free secure WAN” and is the result of a project started by John Gilmore, who wanted to 
make an IPSec implementation for Linux available for free. FreeS/Wan works with RSA 
and is easy to configure. For each IPSec node an RSA key pair has to be created and the 
allowed connections have to be described in a configuration file. In Secure Mobile IP 
implementation FreeS/Wan would do the following: 

• Negotiate keys between MN and Home Firewall 

• Establishing secured tunnels between MN and Home Firewall 

• Encrypting and authenticated all data between MN and Home Firewall. 

2. Dynamics in Secure Mobile IP 

In Secure Mobile IP implementation, the job of Dynamics Mobile IP would be the 
following: 

• Handling agent advertisements (home and foreign) 

• Establishing Mobile IP tunnels between HA and MN 

• Capturing and redirecting packets for MN on the home network. 
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D. INITIAL TRIAL 


Initially, we conducted the Mobile IP implementation using the wired interface 
instead of wireless with both static IPs and dynamic IPs for the mobile node. We used a 
D-Link Ethernet card for the mobile node. We faced some difficulty at first (see 
Problems section) but we finally were able to find the configuration parameters that 
allowed us to move on to try wireless. Once we saw that the tunnels were correctly 
getting built and torn down, we knew that we could move on. 


E. WIRELESS 

After our initial trial, wireless was trivial. The only problem that we had with it 
was that we had to reactivate the wireless Ethernet card every time we entered a different 
subnet. This was an annoyance, but we determined that it was not because of the Mobile 
IP implementation but rather, it was a problem with the OS drivers. Other than that, 
performing the implementation wirelessly worked like the initial wired trial. 


F. DIFFICULTIES ENCOUNTERED 

We believe anyone trying to implement Mobile IP will find this section most 
useful. We found that when searching through many documents, the problems section 
was most useful because it contained similar problems that others were experiencing. 
This section will cover the problems we encountered. Some of the problems we faced 
were not directly associated with Mobile IP. However, it is important to point out these 
problems, as they are necessary steps in getting Mobile IP to work. 

1. Installing the Wireless Card 

The first problem we ran into was setting up the wireless card on the MN. We 
installed the latest driver for the wireless card, linux-wlan-ng-0.1.16-pre9.tar.gz. The 
implementation chapter discusses the necessary steps to install the card. After the 
installation, we were unable to communicate on the network. We edited the /etc/stab file 
with the following changes: 


70 



Socket 0: Instant Wireless Network PC Card 


0 network Orinoco_cs 0 ethO 

Initially, Socket 0 did not contain any information. After inserting this information into 
the parameter and rebooting, the NIC card was able to communicate on the network. 


2. Problems with Dynamics 

In Redhat 7.3, ipchains is loaded and runs by default. The ipchains module is 
contained in Linux Kernel versions 2.1.102 and above, and is required to administer IP 
packet filters. With a full-installation, it incorporates firewall rules automatically into the 
operating system. In Linux kernel versions 2.4.x and above, ipchains is replaced by 
iptables, which has the same functionality. However, iptables does not automatically 
include filtering rules during installation. Redhat 7.3 was installed on our router and 
Redhat 8.0 was installed on our agents. 

Running the command ‘ipchains -L’ shows the configured filtering rules. Since 
our router loaded ipchains by default, it was necessary to turn it off to allow all packets 
through. The command, ‘ipchains -F’ disabled the filtering rules and allowed all packets 
through, including the Mobile IP registration packets. 

Another difficulty we faced was with the assignment of the CCOA using DHCP 
in MN Decapsulation mode. In the Mobile IP protocol, when the CCOA gets assigned to 
the MN, it is considered to be the endpoint of the tunnel. However, this was not the case 
in Dynamics. The endpoint of the tunnel was assigned as the IP address of ethl on the 
FA (Figure 31). During registration, the MN should communicate directly to the HA. 
Using the ‘dynha_tool’ tool we were able to determine if the tunnels were up and if there 
were any errors. The tool reported the tunnel (tunlO) with an IP address of 10.3.4.25. 
However, we were unable to communicate through the tunnel interface. Upon further 
observation, ‘dynha_tool’ reported the warning message ‘Registration for this FA failed, 
trying to find a new one’. This showed that the MN was trying to register through the 
FA, which was not supposed to happen. 
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VI. CONCLUSIONS 


A. MOBILE IP CONCLUSIONS 

Mobile IP is the protocol of choice to support mobility in wireless data 
networking, but issues such as security and performance need to be improved in order for 
it to become more widely accepted. It solves many questions about mobility, but it also 
introduces a lot of questions about security, including data privacy, data integrity and 
authentication. Our research focused on security enhancements for Mobile IP. The 
specific security enhancement that we chose was IPSec within Mobile IP. 

We used the Dynamics-HUT implementation of Mobile IP and Marc Danziesen’s 
version of Secure Mobile IP (SecMIP), to conduct our research. We explored each 
implementation thoroughly by setting up a small Mobile IP network. This enabled us to 
examine how Mobile IP operated. 

Setting up the small network seemed trivial, at first glance, but we encountered 
many difficulties along the way. Issues such as poor documentation and dysfunctional 
network card driver made it difficult to get started. Once we had all the hardware and 
operating systems set up, we ran into further difficulties. 

Installing the Dynamics-HUT Mobile IP implementation was not very difficult 
but we encountered many difficulties in running it correctly. Since the documentation on 
the implementation was scarce, we had to figure things out as we went along. We did 
find other sources that implemented Mobile IP using Dynamics, which helped. Using 
other sources was the key to figuring out how to make it run correctly. 

We first ran the Mobile IP implementation without wireless interface. This 
enabled us to check that the implementation ran correctly. After several trials, and after 
fixing several problems, we switched over to the wireless interface. Running the 
implementation wirelessly did not pose any big problems for us. We ran into minor 
issues, which were more of a hassle than problems. Once we were able to run the Mobile 
IP implementation, we were ready to incorporate IPSec. 
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To incorporate IPSec, we had to make a few changes to the configurations of the 
computers and configurations of the Mobile IP implementation. Making those changes 
was not a problem. Our problem was getting the Mobile IP implementation to run 
correctly with the new settings. 

Mobile IP supports mobility in every sense of the word. It allows mobile nodes to 
roam different networks without losing communication, while keeping the same IP 
address. The speed of technology will only make this protocol better and more widely 
used. Incorporating security functions will provide confidence to users of it. In time, 
Mobile IP will continue to progress and improve. 


B. FUTURE WORK 

People everywhere are catching on to the world of wireless. People want to be 
connected anywhere, any time. The growth of technology has enabled wireless devices 
to be evermore popular. However, there are many areas in which Mobile IP require 
research. Some of them include: 

• Integrated security in Mobile IP 

• Mobile IP Continuous Streaming Data 

• Mobile IP implementation strategy 

• Mobile IP Scalability Measurement Issues 

• Mobile IP and IPSec 

To implement a more secure wireless data network than is currently supported by 
Mobile IP, the IPSec tunnel needs to surround the Mobile IP tunnel, providing integrity, 
authentication and data privacy, wirelessly over a network. The data packets can then be 
delivered with confidence without sacrificing security. 

Wireless mobility is a growing demand. And, as technology gets more advanced, 
the ability to stay connected any where, any time, will be realized. Each one of these 
areas of research could potentially enhance the functionality and performance of Mobile 
IP. 
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